1. Field of the Invention
The present invention is generally directed to a method and system for providing an implicit unknown value to user defined enumerated type data constructs in a Hardware Descriptive Language (HDL) system while maintaining the semantics of the language reference model. More specifically, the present invention is directed to a method and system operable during HDL design compilation and simulation for automatically and seamlessly creating an implicit unknown value in user defined enumerated data types and accounting for the implicitly defined unknown value in ensuring that the semantics of the existing code which depends on the enumerated type are not broken. Further, the present invention is operable to model power shutoff behavior of user defined enumerated type data constructs.
2. Description of the Related Art
Typically, in computer aided Hardware Descriptive Language (HDL) design, a user specifies certain elements or components of an integrated circuit and their behavior and timing elements. In HDL users generally define variables and structures that will be used to represent certain states or behaviors. Any given HDL design may have thousands of these variables or structures.
Ensuring that these variables or structures have all been properly initialized into a known state is very important. Individually checking to ensure that all variables or structures in an HDL design are properly initialized is an extremely laborious task and is indeed quite impractical.
Creators of HDL designs had to explicitly create an additional data state representing an uninitialized value. The creator would then need to ensure that every variable/structure was in this uninitialized state at instantiation. Each creator of an HDL design would then need to assess the impact of this additional state on the remainder of the code, taking into account the desired behavior of the design and ensuring that each addition of the uninitialized state didn't break the desired behaviors. For each behavior that would be broken, users/creators needed to modify the code to be compatible with the inserted uninitialized states.
A creator of an HDL design would then check the values of variables/structures to ensure that they were not in the uninitialized state. This would then imply that each variable/structure in the design had been properly initialized at some point. If a variable was still in an uninitialized state, then the creator would have to go back to the HDL design code and see where the problems were. Through many iterations, the user would remove these problems and a final/golden HDL code could be created.
This golden HDL code would then be simulated and once finally acceptable, the creator would then have to be modified to remove all references to the uninitialized state. All modifications to behaviors or functions that had been made to be compatible with the inserted uninitialized state would have to be removed. Then, this “golden” code, though highly modified would pass to synthesis to be fabricated. If any of the potentially thousands of variables or structures had been left with the additional uninitiated state, or any of the behaviors/methods/functions had been left in the altered state, then additional, extraneous hardware logic would actually be fabricated wasting large amounts of materials, costs, and time.
Therefore, users or designers who want to accurately model or simulate a device typically do not want to explicitly create HDL code themselves representing an imaginary or unknown value such as U or X. Defining constructs that include these unknown U or X values in the HDL design code, and neglecting to remove them before synthesis will result in the disadvantageous result of being synthesized into actual physical silicon chips and extraneous circuitry being built-in for these states that don't need to be kept track of in a designs hardware implementation.
Inasmuch as users don't want to have to create unknown or undefined values such as U or X, modify the existing code to accommodate them, then remove all undefined values and modified code, the task is left to the creator of the compiler and simulation software to implicitly generate these features and yet maintain compatibility with language requirements and compatibility with the individual user's/creator's code representing the hardware implementation of the design.
This presents a formidable challenge in HDL designs where potentially thousands of lines of code have already been generated. Compatibility therewith and with preexisting standards of the language must be maintained while attempting to predict what the user wants/needs to be able to model.
There is therefore a need for a method and system whereby an implicitly defined unknown literal value is created and maintained apart from a user's hardware descriptive language design code and yet compatibility is maintained with the Language Reference Model and the individual HDL design code.
There is therefore a need for a user to be able to automatically simulate different power states as applied to a design without creating extraneous code or extraneous circuitry to perform these tasks.
There is therefore a need for a user to be able to ensure that all variables/constructs are properly initialized without having to modify the HDL design code numerous times or risk generating wasteful logic.